home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / cbm / 3132 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.6 KB
  1. Path: diku.dk!diku2471
  2. From: diku2471@diku.dk (ASGER ALSTRUP NIELSEN)
  3. Newsgroups: comp.sys.cbm
  4. Subject: Re: Programming (assembler) Question
  5. Date: 29 Feb 1996 11:19:54 GMT
  6. Organization: Department of Computer Science, U of Copenhagen
  7. Sender: diku2471@alvis.diku.dk
  8. Message-ID: <4h424q$613@odin.diku.dk>
  9. References: <0lB_Eq200bkw1YeEk0@andrew.cmu.edu>
  10. NNTP-Posting-Host: odin.diku.dk
  11. X-Newsreader: NN version 6.5.0 #13
  12.  
  13. William Nolan <wnolan+@andrew.cmu.edu> writes:
  14.  
  15. >Okay, here's my problem.  In a lot of my Turbo Assembler programs, I
  16. >use the * directive several times to place data at the appropriate
  17. >locations in memory (ie sprite data, character set data, etc).  When I
  18. >compile and run under Turbo Assembler, these programs work fine, since
  19. >I assume that as it assembles, TA puts the data in the right places in
  20. >memory.  But when I compile to object code and save that to disk, the
  21. >often programs stop working.  So I was wondering what to do about
  22. >this?  Any ideas?  Thanks!
  23.  
  24. You've ran into The First Limitation of Turbo Assembler.
  25.  
  26. It's not possible to use the *=adress statement if you want valid
  27. object-files.
  28. The reason lies in the binary format used by commodore. In this native
  29. object-format used by Turbo Assembler, it is not possible to have more
  30. than one starting address of any program.
  31. You can partly solve the problem by splitting your source-file, but
  32. this is not always an option because of global variables which have to
  33. be defined in all source-files, which isn't easy because you cannot
  34. include files in TA.
  35. The usual solution is to compile to memory and save directly from memory
  36. using a monitor. Some enhanced versions of TA can save memory directly
  37. with some <- command.
  38. If your program assembles to areas which ruin something (like TA itself),
  39. you should get a REU (ram expansion unit) and use a REU-version of TA.
  40. Alternatively, you can use the .offs directive, which causes the object
  41. code to be place at a different address in memory eventhough it's
  42. compiled as if it was placed at another place:
  43.  
  44.     * = $2000
  45.     .offs $1000
  46.     
  47. loop    lda $d012
  48.     sta $d020
  49.     jmp loop
  50.  
  51. This will be assemblied and placed at $3000 ($2000+$1000), but the
  52. jmp-statement will be assembled as jmp $2000.
  53. The .offs statement is general, so if you do:
  54.  
  55.     * = $2000
  56.     .offs $1000
  57.     
  58. l1    jmp l1
  59.  
  60.     * = $2100
  61.     
  62. l2    jmp l2
  63.  
  64. you will end up with assembled code at $3000 and $3100.
  65.  
  66. This issue is general to most assemblers on the C64. Some fix the
  67. problem correctly and generate several object files where each
  68. correspond to a *=address block. On other architechtures, the
  69. problem is addresses by the linker, but I have not seen such a
  70. thing for the C64 yet.
  71.  
  72. From time to time, formats for allowing relocatable code is dis-
  73. cussed here, and various formats have been proposed. Some of those
  74. formats could solve this, but I have yet to see an implementation.
  75.  
  76. Meanwhile, go back and reconsider your code. Why do you use the
  77. *=address statement more than once? Why don't you just load your
  78. data instead of using .data statements. This will save space
  79. and will speed up your compile. Already, you must use a separate
  80. file for the music, don't you?
  81. Serious demo-hackers don't mess up their sourcefiles with charsets
  82. and sprites. If they do, they put it right after the code, and code
  83. a small movement-routine that places the data the appropriate places.
  84. This approach allows you to do your entire demo in one piece, which
  85. can be packed directly by your favourite packer. But once again,
  86. keep the graphics out of the source!
  87.  
  88. If you need control of pages, consider putting the timecritical code 
  89. in the beginning of your program.
  90.  
  91. If you have other reasons, you're screwed.
  92.  
  93. Greets,
  94.  
  95. Asger Alstrup
  96.